This chapter identifies features and functionality added to or modified for the following products in one or more releases.
Additional information on the items listed in this chapter is available in the documentation listed in the table below.
|
Cisco ASR 5000 Series GTPP Storage Server Installation and Administration Guide
|
|
Cisco ASR 5000 Series Mobility Unified Reporting System Installation and Administration Guide
|
|
Cisco ASR 5000 Series Aggregation Services Router Hardware Installation and Administration Guide
|
|
Cisco ASR 5000 Series Packet Data Gateway/Tunnel Termination Gateway Administration Guide
|
|
Cisco ASR 5000 Series Subscriber Service Controller Installation and Configuration Guide
|
|
Cisco ASR 5000 Series Policy Provisioning Tool Installation and Configuration Guide
|
|
Open Source Software Licenses for Cisco ASR 5000 Series Multimedia Network Core Platform
|
Bearer-Usage AVP Value for Primary/Secondary Contexts - Behavioral Change
In the earlier releases, the Bearer-Usage AVP was encoded with the value GENERAL(0) irrespective of whether the context is primary or secondary in the Diameter Gy CCR message.
In the current release, the Bearer-Usage AVP will be encoded with the value GENERAL(0) for Primary-PDP context/default bearer and with the value DEDICATED(2) for all secondary-PDPs/dedicated bearers.
In the earlier releases, when there were no static rules configured in the chassis and if the PCRF returns a error-result code in CCA-I with CCFH action as continue, then the call was not terminated.
In the current release, P-GW terminates the call even if the static rules are not configured and an error-result code is returned in CCA-I with CCFH action set as continue.
In the earlier releases, CCR-T was sent when a permanent failure result code (5xxx result codes) was received and the Disconnect reason was "ims_auth_decision_invalid".
In the current release, the call is dropped without sending CCR-T when the permanent failure result code (5xxx result codes) is received and the Disconnect reason will be "ims-authorization-failed".
In the earlier releases, the configuration of Diameter nodes and host strings like endpoint name, peer name, host name, realm name, and fqdn were case-sensitive. Hence, it was difficult to handshake with an external node with the name specified in a different case. That is, if a peer is configured as peer.cisco.com, it failed to open connections from a peer identifying as PEER.cisco.com. Also, configuring endpoints with different cases duplicate the configuration. For example, when configuring endpoints ep1 and EP1, it will assume it to be different and add these separately in the configuration.
In the current release, all the Diameter related node IDs are considered case insensitive. This change applies to both the local configuration and communication with external nodes. When configuring endpoints s6a-endpoint-mme, S6A-endpoint-MME, S6A-ENDPOINT-MME, all these three will be considered the same.
Diameter load balancing implementation maintains a fixed number of servers active at all times for load balancing in case of failures. This can be done by selecting a server with lower weight and adding it to the set of active servers.
|
l
|
Endpoint configuration is needed to specify the minimum number of servers that needs to be active for the service.
|
|
l
|
If any one of the servers in the current active group fails, one of the idle servers needs to be selected for servicing the new requests.
|
eG-CDRs can be in ASN.1 format or in delimiter-separated ASCII format. Configuring the eG-CDR encoding type is a CLI-configurable parameter. The default encoding type is ASN.1. When configuring the eG-CDR encoding type as ASCII, the delimiter character can be specified as either “:” (colon), “,” (comma), or “|” (pipe). The default delimiter character is “|” (pipe).
In the current releases, the Bearer-Usage AVP is sent only during the establishment of bearers in CCR-I and CCR-U with bearer operation as “Establishment”. This condition is imposed because the session level CCR-U is intended for the entire session and not for a particular bearer.
Encoding of Destination-Host AVP in Initial-Request Messages - Behavioral Change
In the earlier releases, the Destination-Host AVP was not sent in session-setup/initial request (first message sent on that interface for that subscriber. This message will vary with different interfaces. For example, CCR-Initial for Gy, ACR-start for Rf, and so on). Also, Destination-Host AVP was not sent in retried requests. For example, CCR-Update failed to be responded by server. The message was retransmitted to alternate server.
In both these scenarios, it is not known which server will respond to the initial/retried message, so the Destination-Realm is encoded but not the Destination-Host. Only after a response for this message is received from one of the hosts present in that realm, the session is considered to be BOUND with that server. Any message sent after this binding will have the Destination-Host AVP encoded.
In the current release, with the CLI command "destination-host avp session binding … ", if the application has selected one of the servers using application-level commands like peer-select command in case of credit-control or diameter authentication/accounting server command in AAA group, encoding of this AVP in initial/retried request is configurable.
Encoding of Network-Request-Support AVP in CCR Messages - Behavioral Change
In the earlier releases, the Network-Request-Support AVP was sent in CCR-T and session level CCR-U messages.
In the current release, if the network-initiated bearer establishment request procedures are not applicable during IP-CAN session establishment, this AVP will not be encoded in CCR-I and in the subsequent messages unless the AVP value is toggled from 1 to 0 and vice-versa.
If the network-initiated procedures are applicable during IP-CAN session establishment, this AVP will be encoded only in the CCR-I and not in the subsequent messages including session level CCRs unless the AVP value is toggled.
Encoding of QoS-Upgrade and QoS-Negotiation AVPs in CCR Messages - Behavioral Change
In the earlier releases, the QoS-Upgrade and QoS-Negotiation AVPs were sent in session level updates and in CCR-T message.
In the current release, as the QoS-Upgrade and QoS-Negotiation AVPs are applicable to bearer, these AVPs will no longer be sent in the CCR-U and CCR-T messages.
In the earlier releases, in the case of failure handling, if the CLI command “failure-handling cc-request-type …“ is configured twice under ims-auth-service then the following error message "Failure: Apply config error" is displayed. For example, if the failure-handling configured is "X" and if the same failure-handling "X" is applied again then the error message "Failure: Apply config error" is displayed.
In the current release, if the same failure-handling configuration is applied under IMSA service then the configuration is accepted as valid and it does not throw any error message.
This release supports the RADIUS Fire-and-Forget feature in conjunction with GGSN for secondary accounting (with different RADIUS accounting group configuration) to the RADIUS servers without expecting acknowledgement from the server, in addition to standard RADIUS accounting. This secondary accounting will be an exact copy of all the standard RADIUS accounting message (RADIUS Start / Interim / Stop) sent to the standard AAA RADIUS server. For this configuring secondary AAA accounting group for the APN is supported.
This release also supports the No-ACK RADIUS Targets feature in conjunction with PDSN and HA for secondary accounting (with different RADIUS accounting group configuration) to the RADIUS servers without expecting the acknowledgement from the server, in addition to standard RADIUS accounting. This secondary accounting will be an exact copy of all the standard RADIUS accounting message (RADIUS Start / Interim / Stop) sent to the standard AAA RADIUS server. For this configuring secondary AAA accounting group for the subscriber template is supported.
In the earlier releases, when the Diameter proxy was not configured, the grouped AVP “Vendor-Specific-Application-Id” in CER/CEA messages contained all the Vendor IDs present in the dictionary file. Hence, if the Gx application used a Customer Specific AVP, this Vendor ID was also added in the Vendor-Id of Vendor-Specific-Application-Id AVP.
In the current releases, if use-proxy is not configured in the Diameter endpoint, the Vendor-Specific-Application-Id AVP in CER/CEA messages will contain only the 3GPP Vendor ID (10415) in the Vendor-Id of the Vendor-Specific-Application-Id AVP.
Multiple-Services-Indicator AVP in Diameter CC Requests - Behavioral Change
In the earlier releases, Multiple-Services-Indicator AVP was sent in all diameter CC request messages - CCR(I/U/T).
In the current release, Multiple-Services-Indicator AVP will be sent in CCR-Initial message only. This AVP will not be sent in update/terminate requests. This is applicable for all Gy dictionaries.
Notification of Bearer Session Termination During Failover - Behavioral Change
In the earlier releases, if in a scenario where there are multiple network initiated bearers and one UE initiated bearer and if only UE initiated bearer is down,
|
l
|
the PCRF was not notified about the bearer deletion i.e., a CCR-U with bearer operation termination was not sent to the PCRF.
|
|
l
|
Also, the “show ims-authorization sessions full all" CLI command displayed one IMSA session after the deletion of UE initiated bearer.
|
|
l
|
PCRF will be intimated about this bearer deletion i.e., a CCR-U with bearer operation termination will be sent to PCRF. Subsequently, a new IMSA session will be created for one of the existing network initiated bearers (Normally IMSA session will be created ONLY for UE initiated bearers).
|
|
l
|
Before receiving the answer (CCA) from PCRF, the "show ims-authorization sessions full all" CLI command will show two IMSA sessions.
|
|
l
|
After receiving the answer (CCA) from PCRF the "show ims-authorization sessions full all" CLI command will show one IMSA session.
|
Whenever RADIUS/Diameter prepay server blacklists content the packets are generally discarded. To enable redirection of such content, post-processing on blacklisted content is required. With this change, RADIUS/Diameter Credit-Control application will decide on whether to allow post-processing to be enabled or not for the blacklisted content.
In release 12.0, in the ACS Rulebase Configuration Mode, the following configuration is available to enable post-processing priority based rules for content in blacklisted state.
Release 12.0 onwards “cca quota-state ...” and “cca redirect-indicator ...” ACS ruledef commands should be used as a post-processing rule. And, “post-processing policy always” command should be configured in the ACS Rulebase Configuration Mode for these post-processing rules to be enabled for blacklisted content.
IMPORTANT: In existing deployments, this requires changes to configurations with quota-limit rules for certain features to work.If this configuration change is not undertaken, when the content is blacklisted and for any packet that can be redirected and that matches this blacklisted content, then redirection will not happen based on “flow action redirect-url” command.
In the current release, the Diameter routing logic has been modified to enable routing to destination hosts that are not directly connected to the Diameter clients like GGSN, MME, PGW, and that does not have a route entry configured. Message routing to the host is based on the realm of the host.
For a given session towards a Destination Host, all the messages belonging to the session will be routed through the same peer until the peer is down. If the peer goes down, for the subsequent messages failure handling mechanism will be triggered and the message will be sent using other available peers connected to the destination host.
In the earlier releases, if Revalidation-Time AVP sent in CCA-I message by PCRF fails sanity checks, call is terminated with the Termination-Cause AVP set to the value DIAMETER_BAD_ANSWER (3).
In the current release, the call will continue irrespective of the sanity failure status of Revalidation-Time AVP in the CCA-I message.
This release of StarOS incorporates the initial hooks required to support Cisco Smart Call Home (SCM). Smart Call Home is a powerful service capability of Cisco SMARTnet® Service that offers real-time alerts, remediation, and personalized web-based reports on select Cisco devices. Customers and the Technical Assistance Center (TAC) get the information they need to quickly identify and resolve network issues rapidly.
|
l
|
Providing a continuous connection to Cisco that provides monitoring, real-time troubleshooting, alerts, and remediation on select Cisco “call home” enabled devices.
|
|
l
|
Automatically generating a Cisco Service Request for severity 1 problems and is sent to the appropriate engineer at TAC.
|
|
l
|
Giving the customer greater visibility into network performances through Call Home messages, recommendations, inventory, field notices, security advisories, and End-of-Life notices for select Cisco devices through a Web-based portal.
|
Full support for Call Home functionality will be introduced later this year. Smart Call Home will be available as part of a Cisco SMARTnet Service contract.
This release supports TACACS+ authentication, authorization and accounting services for ASR 5000 administrative users.
For more information on TACACS+ configuration and maintenance, refer to the ASR 5000 Series System Administration Guide, the ASR 5000 Command Line Interface Reference, and the ASR 5000 Statistics and Counters Reference.
In release 12.0, in the Policy Control Configuration mode, the following configuration is available to upgrade any 3GPP release based dictionary to higher version.
Release 12.0 onwards, if a Rel. 7 based dictionary is already configured with diameter dictionary dpca-custom4 command, and then if the diameter update-dictionary-avps 3gpp-r9 command is applied, the Supported-Features AVP with feature bit 1 being set will be sent in the CCR-I to indicate that 3GPP Rel. 9 AVPs are also supported.
|
In the CCR-I, Supported-Features AVP will be encoded with value 2 for the Feature-List AVP.
The Feature-List AVP value suggest that it is 3GPP Rel. 9 compliant. But, it is not fully complaint to 3GPP Rel. 9.
In the current release, for this upgrade scenario (3GPP Rel. 7 to 3GPP Rel. 9), only volume reporting related AVPs mentioned in the 3GPP Rel. 9 will be supported.
|
|
|
In the CCR-I, Supported-Features AVP will be encoded with value 1 for the Feature-List AVP.
The Feature-List AVP value suggest that it is 3GPP Rel. 8 compliant. But, it is not fully complaint to 3GPP Rel. 8.
In the current release, for this upgrade scenario (3GPP Rel. 7 to 3GPP Rel. 8), none of the features mentioned in 3GPP Rel. 8 will be supported.
|
|
|
In the CCR-I, value for the Feature-List AVP in the Supported-Features AVP will be 2.
The Feature-List AVP value suggest that it is 3GPP Rel. 9 compliant. But, it is not fully complaint to 3GPP Rel. 9.
Currently for this upgrade scenario (3GPP Rel. 8 to 3GPP Rel. 9), only volume reporting related AVPs mentioned in 3GPP Rel. 9 will be supported.
|
In the earlier releases, for Default-EPS-Bearer-QoS AVP, the IMSA validation for Quality of service Class Identifier (QCI) range was performed based on standard specifications. The ranges 1–9 and 128–254 were considered valid.
In the current release, the range 1–32 is valid. This change has been implemented to align with the configurable QCI range that the CLI supports.
This Diameter-related behavioral change is applicable to all products that use the STa and S6b application interfaces.
In the earlier releases, CER/CEA for STa and S6b applications included all the vendor-ids supported by the dictionary in Vendor-ID AVP under Vendor-Specific-Application-ID Grouped AVP. However, per the specification, it should include only 3GPP Vendor-ID (10415) as these are 3GPP specific applications.
In the current release, for the STa and S6b applications, the CER/CEA will have only 10415 (3GPP Vendor-ID) as Vendor-ID AVP value under Vendor-Specific-Application-ID AVP.
|
l
|
Total threshold level along with uplink/downlink threshold level is treated as an error and only total threshold level is now accepted.
|
|
l
|
Enabling and disabling session usage in a single message from PCRF is now supported. This is only if the monitoring key is associated at session level.
|
|
l
|
If no new threshold is provided in response for the usage report, monitoring is stopped. Earlier workaround to stop monitoring by providing the Usage-Monitoring-Information AVP but without threshold is now not applicable.
|
|
l
|
Monitoring usage based on input/output octet threshold levels is now supported. Usage is reported based on the enabled threshold level. If multiple levels are enabled, usage will be reported on all the enabled levels even if only one of the levels is breached. Monitoring will be stopped on the missing threshold levels in the response for the usage report from PCRF (expected to provide the complete set again if PCRF wants to continue monitoring on the multiple levels enabled earlier).
|
|
l
|
For more information on Volume Reporting over Gx feature, refer to the Gx Interface Support appendix in the core network service administration guide.
This section provides information on new Application Detection and Control (ADC) features in Release 12.0.
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
|
l
|
WiMAX HA and ASN-GW have been enhanced to support profile-based hotlining as per WiMAX Forum™ Network Architecture, NGW 1.5 specification. See Interface Changes for additional information.
802.1p marking is now supported on ASN-GW with or without Ethernet CS support. See Interface Changes for additional information.
Support has been added for IP 5-tuple flow-based prepaid accounting using ECSv2 rulebase configuration support for WiMAX, ASN-GW and HA calls.
Also added Hotlining support for IP 5-tuple flow-based prepaid call sand postpaid sessions on WiMAX, HA and ASN-GW.
ASN-GW now supports a single DCCA session for all the bearers in an IP-CAN Session. See Interface Changes for additional information.
Added and modified CLI commands to support PHS for WiMax Calls. See Interface Changes for details.
Added and modified CLI commands to support PHS for WiMax Calls. See Interface Changes for details.Feature
fa-ha-spi remote-address <ip_address> spi-number <spinumber> secret <secret > [allow-fa-ha-auth-extension | disallow-fa-ha-auth-extension]
A new, HA-specific dictionary has been added as “custom53”. This dictionary contains a specific set of UQ Communications (UQC) AAA attributes.
The ASN-GW can now send the RADIUS test frame (Auth Req and Acct Req) with the exact attribute set identified for the UQC dictionary.
|
l
|
IP 5-tuple [Source IP, Destination IP, Source Port, Destination Port, Protocol] flow-based prepaid accounting using ECSv2 rulebase configuration for WiMAX ASN-GW and HA calls.
|
|
l
|
Hotlining support for postpaid sessions on WiMAX HA and ASN-GW. A session can be hotlined either at the beginning or middle of the session.
|
|
l
|
Idle Mode Entry – If asn-policy idle-mode is enabled, then Interim-Update will be sent with the BSID and WiMAX-Idle-Mode-Transition as "Idle".
|
|
l
|
Idle Mode Exit – If asn-policy idle-mode is enabled, then Interim-Update will be sent with the BSID and WiMAX-Idle-Mode-Transition as "Not Idle".
|
|
l
|
Location Update – If asn-policy notification-handoff is enabled, the Interim-Update will be sent with the BSID and SN-Handoff-Indicator as "Location-Update".
|
|
l
|
Handoff –If asn-policy notification-handoff is enabled, the Interim-Update will be sent with the BSID and SN-Handoff-Indicator as "Active-Handoff".
|
|
l
|
Interim when the call is Idle – During the Idle-Mode Entry, the Interim will not be sent until the Idle-Mode Exit or Location Update.
|
This release provides support for IPv6 and ICMPv6 Firewall. IPv6 Firewall supports the following features:
|
l
|
Enabling/Disabling IPv6 Firewall: The configuration can be used to enable or disable IPv6 Firewall for subscribers. IPv4 and IPv6 Firewall can be enabled or disabled separately.
|
|
l
|
IPv6 Header checks: Firewall performs the following header checks to ensure the integrity of an IPv6 packet. IPv6 packets with unknown extension headers will not be dropped by Firewall; such packets will be allowed by Firewall.
|
|
l
|
Hop-by-hop Options filtering: The Hop-by-Hop options will be parsed only if any of the Hop-by-Hop dos protections is enabled.
|
|
l
|
IPv6 Rule-match: Stateful Firewall access ruledefs are enhanced to support IPv6 addresses and other parameters like IP version and ICMPv6 protocol.
|
|
l
|
IPv6 Recovery: Stateful Firewall supports IPv6 flow recovery similar to IPv4 flows with the existing flow-recovery CLI being applicable to IPv6 flows also.
|
For more information, please refer the Personal Stateful Firewall Administration Guide and CLI Reference Guide.
For information about the Femto Network Gateway, see the Femto Network Gateway Administration Guide.
GGSN controls the assignment of different radio interface QoS priorities (gold/silver/bronze) via the PCRF Gx interface during PDP context setup (CCR/CCA-I). This is performed using the Allocation Retention Priority (ARP) parameter (AVP code 1034) as specified in 3GPP TS 29.212, with values = 0-3; ARP values from the PCRF other than 0-3 are ignored. During PDP context setup the PCRF returns the ARP value in CCA-I and this ARP is then assigned/negotiated with the SGSN and RNC.
This section provides information on new features supported on HNB-Gateway (HNB-GW) in Release 12.1.
In this release multiple MSC selection without Iu-Flex functionality for HNB-GW service is supported.
HNBGW can connect to multiple MSC and SGSN through Iu-Flex or LAC mapping. This feature implements the multiple MSC selection using LAC.
For this support the HNB-GW uses HNB's LAC, received during registration procedure in HNB_REGISTER_REQUEST message, to distribute RANAP-Initial UE message to an MSC. It maps the LAC with MSC point code and a set of LACs configured for each MSC, connected to the HNB-GW.
This section provides information on new IP Services Gateway (IPSG) features in Release 12.0. For more information on IPSG, refer the IP Services Gateway Administration Guide.
The S3 interface facilitates user mobility between an MME and a Release 8 SGSN providing for the transfer of the UE context between the MME and the SGSN.
Circuit Switched Fall Back enables a UE to camp on an E-UTRAN cell and originate or terminate voice calls through a forced switchover to the CS domain.
IP Security (IPSec) on the S1-MME interface is a node-to-node IKEv2 tunnel that can be configured to assume the characteristics of either a pre-configured tunnel or a dynamic tunnel.
Pre-configured node tunnels are fully qualified IPSec tunnels. Each IPSec tunnel is configured with parameters including pre-shared key, local and remote IP addresses, crypto hashes, groups, algorithms and the access control list (ACL).
Node-to-node dynamic tunnels are generated dynamically as the connections are initiated by different nodes in the LTE network. Each IPSec tunnel does not need to be pre-configured for each required parameter, instead it uses a common template for some parameters, like crypto algorithms, hashes, and groups. Other parameters are fetched dynamically from the tunnel requests like IP addresses and traffic selectors. Authentication information is fetched dynamically via certificates.
Typically, the eNodeB initiates an IPSec tunnel to the MME. The MME service is responsible to verify the configuration and use an IPSec API to make the MME listen on the service address for IKE requests.
The S1-MME Interface carries SCTP signaling traffic that flows through an IPSec tunnel if it is configured. When a UE needs to connect to the Internet, it initiates a connection to an eNodeB which then tunnels its traffic to an MME using an SCTP connection. Any further UEs using the same eNodeB to communicate to the same MME will subsequently use the same SCTP and hence the same IPSec Tunnel according to the LTE standard.
The MME service supports up to four SCTP bind end point IPv4 or IPv6 addresses for the S6a interface.
The MME now supports behavior that allows the peer realm of the HSS to be determined by the MCC and MNC in the subscriber’s IMSI. Prior behavior was that the HSS must be statically configured in the MME.
TCP Proxy support is now available for Lawful Intercept on the MME. Contact your local sales representative for detailed information.
|
l
|
Traffic analysis — uplink DSL, downlink DSL and total DSL traffic including daily weekly, and monthly aggregation/distribution.
|
IMPORTANT: The DSL reports can be generated only when DSL is configured as an APN group during MUR software installation/upgrade.Except the TopN% DSL subscribers, all other DSL reports can be viewed under the DPI tab by selecting appropriate dimensional filters.
IMPORTANT: The discrimination between DSL and UMTS traffic will be based on the APN Name attribute in the EDR file.Release 12.0 onwards, for all new deployments of MUR that use either Sun Netra X4270 or UCS C460 M2 server and run Red Hat Linux, L-ESS is NOT required as the ASR 5K EDR module can be configured to push the xDRs directly to the MUR reporting server. Push from ASR 5K is the Cisco recommended deployment model. Currently, L-ESS is supported only on Solaris platforms. Existing deployments where L-ESS is installed, to pull EDRs from ASR 5K, may continue with their deployment model in the 12.0 version of MUR Software Release and later.
MUR has the capability of exporting reports in Comma Separated Value (CSV) format in addition to PDF and Excel formats. This can be accomplished through the GUI by clicking the csv icon available in the tabular representation of all the reports in the HOME and DPI tabs.
From Release 12.0 onwards, MUR no longer supports the limitation of selecting only 15 bulkstats counters/indices at a time. Now, there is no defined limit as such; users are allowed to select any number of counters and indices simultaneously.
Charts will not be displayed if more than 15 indexes or 4 counters are selected. However, the data will be displayed in the Table tab of the BS/KPI reporting page.
MUR generates HTTP User Agent (UA) reports and/or UA group reports that are primarily used for ASR 5000 based Modem tethering detection.
The MUR solution also provides a utility to export Top N User-Agent list to a text file based on the given level of tethered traffic. This text file contains pre-formatted CLI file with the configured ruledefs and group-of-ruledefs that need to be applied to the ASR 5K system.
IMPORTANT: Currently, MUR does not support UA report generation for historical data as the data tables does not contain User Agent, APN, and TAC. Also, note that any changes made to the APN/TAC/UA group configurations will not be applied to the old data.The reporting EDR file contains multiple attribute fields like sn-start-time and sn-end-time; some of them are considered mandatory depending on the gateway and reporting types.
Currently, MUR mandates sn-start-time and sn-end-time fields in the flow EDR. If the EDR contains the fields sn-flow-start-time and sn-flow-end-time then MUR will pick values from these fields. However, the sn-flow-start-time and sn-flow-end-time fields are not mandatory.
In a particular deployment, if the EDR receives only sn-flow-start-time and sn-flow-end-time fields, then the mandatory settings for sn-start-time and sn-end-time should be disabled through the System menu on the GUI.
In the current release, the following limitations were imposed with respect to user permissions and privileges:
|
l
|
All MUR administrators have access to USERS and GROUPS menu in the Admin tab available on the MUR GUI.
|
|
l
|
Administrator with admin user name will have the rights to modify and delete all the MUR users’ accounts. Only users with admin user name can modify its own password. Only admin user will be able to delete any administrator or operator user accounts.
|
|
l
|
Administrator other than users with admin user name will have rights to delete the MUR users except admin user and modify user accounts except their passwords.
|
|
l
|
After modifying user role from Administrator to Operator and vice-versa, the user should alter the configuration on the GUI to lock/unlock the user account accordingly.
|
In this release, a custom Red Hat Enterprise Linux OS (Cisco MITG RHEL v5.5) has been introduced to support MUR running on the Cisco UCS platforms.
Release 12.0 onwards, MUR recommends using UCS C460 M2 server running MITG Customized RHEL 5.5. For information on the complete hardware recommendations and file system supported, refer to the Mobility Unified Reporting System Overview chapter in the Cisco Mobility Unified Reporting System Installation and Administration Guide. For the OS installation information, refer to the Cisco MITG RHEL v5.5 OS Application Note.
IMPORTANT: The Cisco MITG RHEL v5.5 OS is a custom image that contains only those software packages required to support compatible Cisco MITG external software applications. Users must not install any other applications on servers running the Cisco MITG v5.5 OS. For detailed software compatibility information, refer to the Cisco MITG RHEL v5.5 OS Application Note. On selecting multiple counters/indices or a huge data range on the Bulkstats and KPI reporting pages, the MUR server may experience some delay in fetching the report information. If the time taken for this activity is beyond the expected threshold, then these tasks are automatically scheduled to be reported offline at a later period.
An automated offline script at the server side runs every 1 minute to check if the requested report information is available. When it is ready, the server makes it available on Background Task Manager tab present on the GUI. These offline reports are generated in Excel format and provided to users as a zip file.
The current release of MUR allows users to search the bulkstats (BS) counters using the Counters text box newly added in the Bulkstats reporting page, and also find the CLI-equivalent counter names by selecting by CLI Name check box.
With the auto-complete feature available in the Counter text box, you can just key in a few characters and search the counters easily.
MUR users have been provided the flexibility to configure multiple SGSN IP addresses under one SGSN group using “ *”. The SGSN group configuration can be performed on the GUI through System > Reports > SGSN groups menu.
MUR architecture is redesigned so that KPI parser and Bulkstats (BS) parser does not coexist and they function independently from release 12.0 onwards.
The KPI parser now calculates only the values of KPIs for which the alarms are configured through the GUI. This parser uses the information stored by BS parser in the database (DB) for KPI calculations and for sending alarms. This avoids reparsing of the same file and redundant connections to the DB.
KPI parser generates alarms only when the alarm functionality is enabled through the SNMP Configurations option available on the GUI under the System menu.
This section provides information on new Network Address Translation (NAT) features in Release 12.0.
This release provides support for H323 ALG that is designed to traverse NAT by inspecting and altering information contained in existing H323 messages as they pass through the NAT. It can alter address and port information in registration, call signaling and automatically opening pinholes in the NAT to allow media flow.
|
l
|
Call Transfer: The Call Transfer supplementary service enables the served user (User A) to transform an existing call with a User B (primary call) into a new call between current User B and a new User C (transferred-to user) selected by served user A.
|
|
l
|
Call Hold: The Call Hold supplementary service allows the served user, which may be the originally calling or the called user, to interrupt communications on an existing call and then subsequently, if desired, re-establish (i.e. retrieve) communications with the held user.
|
|
l
|
Call Diversion: Call Diversion supplementary service permits a served user to have incoming calls addressed to the served user's number redirected to another number; on busy service, it enables a served user to have calls redirected to another endpoint; on No Answer, it enables a served user to have calls addressed to the served endpoint's number and redirected to another endpoint if the connection is not established within a defined period of time.
|
|
l
|
Call Waiting: The Call Waiting supplementary service permits a busy user to be informed of an incoming call while being engaged with one or more other calls.
|
|
l
|
Call Offering: The Call Offering supplementary service on request from the calling user, enables a call to be offered to a busy user and to wait for that called user to accept the call, after the necessary resources have become available.
|
An application layer gateway, at the Firewall/NAT, examines all the H323 packets and modifies the packet such that all the private addresses are replaced by public addresses. It also opens all the pinholes required for successful call establishment. A NAT aware endpoint establishes end-to-end media session through FW/NAT without the need of ALG. Any TCP connection or UDP packet sent from the internal network through the firewall opens a pinhole dynamically in the firewall. This pinhole allows incoming messages to be sent from the destination of the TCP connection or the UDP packet. The pinhole stays open as long as the network sends information through the pinhole to the same destination.
If an end point supports NAT traversal, H323 ALG disables itself so that end point directly opens required pinhole and establishes media path between them. The ALG will not manage any pinhole for media traversal across Firewall/NAT for NAT aware clients. By default, the ALG will bypass all the clients that support H460.18/19 and H460.23/24.
TCP Proxy support is now available for Lawful Intercept on the PDG/TTG. Contact your local sales representative for detailed information.
This section provides information on new Packet Data Network Gateway (P-GW) features in Release 12.0. Additional information on these features can be found in the Cisco ASR 5000 Series Packet Data Network Gateway Administration Guide and the Cisco ASR 5000 Series Command Line Interface Reference.
When Gn/Gp interworking with pre-release 8 (3GPP) SGSNs is enabled, the GGSN service on the P-GW supports direct tunnel functionality.
The SGSN/GGSN, when co-residing with the S-GW/P-GW, supports all product-level requirements of the S-GW/P-GW for availability, performance, capacity, security, and O+M.
In case of P-GW with GnGp access, after a P-GW mode to GGSN mode handover, SGSN_CHANGE(0) Event trigger and 3GPP-SGSN-Address needs to be sent. The system shall send AN_GW_CHANGE (21) Event-Trigger and IPv4 SGSN address in the AN-GW-Address AVP. This is because SGSN-Address would not have been valid in the case of P-GW with S5/S8 and, hence, SGSN_CHANGE(0) would not be meaningful after a P-GW mode to GGSN mode handover.
The P-GW supports GRE generic tunnel interfaces in accordance with RFC-2784, Generic Routing Encapsulation (GRE). The GRE protocol allows mobile users to connect to their enterprise networks through GRE tunnels.
GRE tunnels can be used by the enterprise customers of a carrier 1) To transport AAA packets corresponding to an APN over a GRE tunnel to the corporate AAA servers and, 2) To transport the enterprise subscriber packets over the GRE tunnel to the corporation gateway.
The corporate servers may have private IP addresses and hence the addresses belonging to different enterprises may be overlapping. Each enterprise needs to be in a unique virtual routing domain, known as VRF. To differentiate the tunnels between same set of local and remote ends, GRE Key will be used as a differentiation.
GRE tunneling is a common technique to enable multi-protocol local networks over a single-protocol backbone, to connect non-contiguous networks and allow virtual private networks across WANs. This mechanism encapsulates data packets from one protocol inside a different protocol and transports the data packets unchanged across a foreign network. It is important to note that GRE tunneling does not provide security to the encapsulated protocol, as there is no encryption involved (like IPSec offers, for example).
|
l
|
Carrier protocol-protocol that does the encapsulating. For example: GRE, IP-in-IP, L2TP, MPLS and IPSec.
|
|
l
|
IMPORTANT: This feature is license dependent. Please contact your local sales representative for more information.gtpumgr now receives IPSec tunnel notifications from IPSec. gtpumgr now updates all sessmgrs with NPU flow information for the tunnel that is received from IPSec.
gtpumgr also notifies all sessmgrs of peer info. so that when any bearer setups for that peer, corresponding IPSec tunnel info. is used for data forwarding.
GTP-U Echoes Sent through IPSec Tunnel for a Peer Once the IPSec Tunnel to the Peer is Set Up
With IPSec tunnels, if gtpumgr restarts, the IPSec tunnel info is now synced up with the IPSec subsystem and sessmgr.
CHANGE_IN_SERVING_NODE trigger is an extension to the CHANGE_IN_SGSN trigger. However, for the purpose of backward compatibility, both triggers are retained. The P-GW sends them in the following manner.
|
l
|
SERVING_NODE AND SGSN is configured on the CLI, system sends SERVING_NODE_CHANGE.
|
|
l
|
|
l
|
SGSN alone (older OCS), then the current behavior of sending CHANGE_IN_SGSN_IP_ADDRESS trigger is retained.
|
|
l
|
SERVING_NODE alone (newer OCS), then the new trigger CHANGE_IN_SERVING_NODE would be sent.
|
MSCC (quota) checkpointing is now handled as part of normal session recovery. MSCC checkpointing occurs randomly (~ 1-2 times within every 60 seconds) on every MSCC update. The MSCC checkpoint will be sent to the peer chassis only if there is a change in MSCC information.
Local QoS policies can be used to control different aspects of a session, such as QoS, Data Usage, Subscription profiles, or Server Usage, by means of locally defined policies.
Local QoS policies are triggered when certain events occur and the associated conditions are satisfied. For example, when a new call is initiated, the QoS to be applied for the call could be decided based on the IMSI, MSISDN, and APN.
IMPORTANT: This feature is license dependent. Please contact your local sales representative for more information.This functionality has been implemented.
Toward P-GW, there is collision scenario when S-GW and P-GW both initiate a tunnel at the same time; however, one of them will terminate.
When enabled through a feature license key, the system includes NEMO support for a Mobile IPv4 Network Mobility (NEMO-HA) on the P-GW platform to terminate Mobile IPv4 based NEMO connections from Mobile Routers (MRs) that attach to an Enterprise PDN. The NEMO functionality allows bi-directional communication that is application-agnostic between users behind the MR and users or resources on Fixed Network sites.
The same NEMO4G-HA service and its bound Loopback IP address supports NEMO connections whose underlying PDN connection comes through GTP S5 (4G access) or PMIPv6 S2a (eHRPD access).
IMPORTANT: This feature is license dependent. Please contact your local sales representative for more information.P-GW Supports Average Throughput Per Active User of 10 Kbps on Uplink and 50 Kbps on Downlink
The P-GW service now supports average throughput per active user of 10 Kbps on uplink and 50 Kbps on downlink.
P-GW Supports Throughput Per Active Video Streaming User Device of 256Kbps on Uplink and 1Mbps on Downlink.
The P-GW service now supports throughput per active video streaming user device of 256Kbps on uplink and 1Mbps on downlink.
Previously, for Default-EPS-Bearer QoS, IMSA validation for QCI ranges 1-9 and 128-254 were considered valid (as per spec).
The IPSec implementation for LTE is only node-to-node. Any IPSec tunnel will handle multiple subscriber GTPU traffic. The IPSec tunnel is generated dynamically as the connection is initiated by nodes in the LTE network. Each IPSec tunnel uses a common template for parameters, such as crypto algorithms, hashes, groups, etc. Other parameters are fetched dynamically from the tunnel requests, such as IP addresses and traffic selectors. Authentication information is fetched dynamically via certificates.
For LTE nodes, IPSec tunnels can be setup for control and data traffic carried over S1-MME, S1-U, S11, and S5.
The configuration monitor utility will perform a show configuration command every 15 minutes and compare the subsequent output to determine whether the information has changed. The configuration is defined as having changed when the current configuration differs from the previous snapshot. If a configuration change is indicated, then an SNMP trap is sent.
Support for Event Trigger UE_IP_ADDRESS_ ALLOCATE and UE_IP_ADDRESS_RELEASE
Added support for displaying event-masks and statistics for Event-Triggers UE-IP-Address-Allocate and UE-IP-Address-Release.
This section provides information on new Session Control Manager (SCM) features in Release 12.0. Additional information on these features can be found in the Cisco ASR 5000 Series Session Control Manager Administration Guide and the Cisco ASR 5000 Series Command Line Interface Reference.
Level 1: For every new call/event received, the system checks if sessmgr memory-usage is above a threshold value (such as 95 percent). If it is, memory-congestion is triggered and new call messages are rejected with 500 SIP response. Memory congestion is disabled when memory usage drops by a tolerance value (default is 10 percent). This functionality has not been tested.
Level 2: If the sessmgr usage reaches 100 percent, all newly received SIP messages are dropped at the socket layer in that sessmgr except for the BYE message. The new SIP messages are not processed until the memory reaches the threshold value (95 percent).
Bridge Mode: CSCF Session and Performance Counters Incremented for VoIP Calls.
When P-CSCF acts in a bridging mode between two services, the show cscf session counters calls <filter criteria> name <service_name> command now displays separate counters for access and core P-CSCF.
Cscfmgr Does Not Drop Register Requests for which Retries Exceeded When Congestion is Turned On in sessmgr
When cscfmgr (demuxmgr) receives REGISTER request from Network, it fetches a suitable sessmgr for processing REGISTER. If that sessmgr rejects the REGISTER since it is overloaded, cscfmgr will retry another sessmgr. If the system is congested, cscfmgr will retry three times to find a sessmgr. If it fails, then cscfmgr will reject the request with a “503 service unavailable” error response with Retry-after header.
CSCF now supports application/vnd.etsi.aoc+xml MIME type as per spec TS 24.647 and proxies the message without parsing the message body.
The SCM now supports redirection on overload (exceeding session/license limit). Overload conditions arise when the maximum session limit per sessmgr is reached or the license is exceeded.
When the CSCF becomes overloaded, an overload policy can be configured to handle it. When the overload condition is hit, the new registrations (SIP REGISTER messages) reaching the cscfmgr are dropped/rejected/redirected based on the configuration.
When CSCF identifies congestion, it originates UMM_RESPONSE with response code set as 500. Sipapp while forming the response SIP_IPS fills the Retry-after header with a random value between 0 to 10 seconds as per RFC 3261.
CSCF Supports RFC 5621 Message Body Handling in the Session Initiation Protocol (SIP)
CSCF has supported “multipart/mixed” message body parsing. It now also supports “multipart/alternative” and “multipart/related” message body parsing.
For Interactive Traffic class, the P-CSCF/A-BG supports per-service configurable DSCP marking for Uplink and Downlink direction based on Allocation/Retention Priority in addition to the current priorities.
I-CSCF Supports the Ma Reference Point for Interfacing to AS to Support Public Service Identity (PSI) Procedures
I-CSCF, upon receiving the terminating request, checks the subdomain-route list for matches. If a match is found the routing will happen based on it. Otherwise, I-CSCF will do a User Location Query (Location-Information-Request) and proceed normally.
P-CSCF Determines the Type of Authentication Based on the Rules in Annex P.3, 33.203 (860)
P-CSCF Rejects Emergency Calls Based on Local-policy/UE-location-network/SDP
P-CSCF will reject an emergency-call with 380 response based on the following local-policies (only if user is not emergency-registered):
|
l
|
User is a visited-ue and makes an emergency-call. Here, visited-ue is determined based on matching of PANI in INVITE with MCC/MNC configured (new-option).
|
|
l
|
Reject emergency-registration from a visited-ue. visited-ue is determined based on the existing functionality of PANI/default-aor-domain match.
|
|
l
|
RAT change notification is now done along with IPCAN change notification (Sec 5.3.13,Sec 4.4.6.4)
|
|
l
|
Specific Action AVP -CHARGING_ CORRELATION_EXCHANGE is now used for correlation exchange. Previously it was made obsolete.(Sec 4.4.6.5)
|
P-CSCF now provides IPv4-IPv6 interworking functionality between IPv4-only UEs and IPv6-only core network elements (I/S-CSCF) by acting as dual-stack.
To achieve the dual-stack behavior, P-CSCF is configured in two services. The first service (V6-SVC) listens on an IPv6 address. The second service (V4-SVC) listens on an IPv4 address. SIP messages coming from IPv4 UEs will come to V4-SVC and be forwarded to the IPv6 core network through V6-SVC. Similarly, messages from IPv6 core network that come to V6-SVC can be forwarded to IPv4 UEs via V4-SVC.
To meet regulatory requirements that deaf/hearing impaired people must be able to perform text-based communication to other users and government offices, the P-CSCF now supports Global Text Telephony.
Global Text Telephony/Teletype messages must use ITU-T Recommendation T.140 for real-time text according to the rules and procedures specified in 3GPP TS 26.114 with the following clarifications:
|
l
|
For real-time text, RTCP reporting is turned off by setting the SDP bandwidth modifiers “RS” and “RR” to zero.
|
For a forking proxy server, the type of directive indicates whether the caller would like the proxy server to proxy the request to all known addresses at once (parallel), or go through them sequentially (serial) by contacting the next address only after it has received a non-2xx or non-6xx final response for the previous one.
The Session-Priority AVP is now sent in Rf charging messages based on the SIP Resource-Priority header.
Transport Layer Security (TLS) provides confidentiality and integrity protection for SIP signaling messages between the UE and P-CSCF/A-BG. TLS is a layered protocol that runs upon reliable transport protocols like TCP and SCTP.
|
l
|
Use of TLS by Security Mechanism agreement between UE and P-CSCF/A-BG, as per RC 3329 and TS 33.203
|
This section provides information on new Serving Gateway (S-GW) features in Release 12.0. Additional information on these features can be found in the Cisco ASR 5000 Series Serving Gateway Administration Guide.
The operator policy provides mechanisms to fine tune the behavior of subsets of subscribers above and beyond the behaviors described in the user profile. It also can be used to control the behavior of visiting subscribers in roaming scenarios, enforcing roaming agreements and providing a measure of local protection against foreign subscribers.
Circuit Switched Fall Back (CSFB) enables the UE to camp on an EUTRAN cell and originate or terminate voice calls through a forced switchover to the CS domain or other CS-domain services (e.g., Location Services (LCS) or supplementary services). Additionally, SMS delivery via the CS core network is realized without CSFB. Since LTE EPC networks were not meant to directly anchor CS connections, when any CS voice services are initiated, any PS based data activities on the EUTRAN network will be temporarily suspended (either the data transfer is suspended or the packet switched connection is handed over to the 2G/3G network).
While the primary responsibility of supporting CSFB fall to the MME, the S-GW supports CSFB messaging over the S11 interface.
This section provides information on new Serving GPRS Support Node (SGSN) features in Release 12.0. Additional information on these features can be found in the SGSN Administration Guide, and in the CLI Reference Guide.
The configuration limits have increased from 32 to 128 for the maximum number of LACs, as a combined total for LACs configured, for pool-areas and non-pool-areas for a Gs Service.
The SGSN now fully supports regional subscription zone identities (RSZIs) in accordance with TS 23.008. The HLR stores a list of RSZIs; 10 per network destination code (NDC). The RSZI are comprised of the PLMN id and the zone code lists. The SGSN now enables the operator to define the zone code lists, to enable zone code checking, and to define the cause code for subscription rejection when it is due to regional subscription information failure.
The SGSN now supports the Network Requested PDP Context Activation (NRPCA) procedure for 3G attachments. Whenever there is downlink data at the GGSN for a subscriber, but there is no valid context for the already-established PDP address, the GGSN initiates an NRPCA procedure towards the SGSN. Prior to starting the NRPCA procedure, the GGSN either obtains the SGSN address from the HLR or uses the last SGSN address of the subscriber available at the GGSN. There are no interface changes to support this feature. Support is configured with existing CLI commands (network-initiated-pdp-activation, location-area-list) in the call-control-profile configuration mode and timers (T3385-timeout and max-actv-retransmission) are set in the SGSN service configuration mode.
For a PDP context request, an invalid APN occurs when none of the APNs in the HLR subscriber profile match the APN sent by the subscriber. The SGSN can now be provisioned to override an invalid APN even when a user has a wildcard APN in the HLR profile. The SGSN’s existing default APN functionality has been enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a Webpage informing the user of the error and prompting to subscribe for services.
Previously, if the required subscription APN was not present in subscriber profile, activation would be rejected.
The SGSN now provides the ability to configure default APN to be used in several different scenarios:
• Use the APN in the first subscription record as a default APN. With this option the first subscription record with matching PDP type and PDP address will be used as the default APN. Here, first record means the first among the records received from HLR in that order. The default APN will be used if normal APN selection fails. This function is enabled via the new key-word ‘first-in-subscription’.
• Fallback to the APN in the first subscription record when configured default APN is not available. It is possible to configure a default APN to be used. However, if the configured default APN is not present in subscription then the SGSN will use the APN in the first subscription record with matching PDP type and PDP address. This function is enabled via the new keyword ‘fallback-to-first-in-subscription’.
• Prefer to use a single subscription record option, which specifies that if normal APN selection fails and if there is only one subscription record, then use the APN in that subscription record as the default APN. This is an optional configuration and is specified along with a default APN to be used. The configured default APN will be used when there are more than one subscription records. This feature is enabled via the new keyword ‘prefer-single-subscription’.
It is now possible to append subscriber charging characteristic (SCHAR) information to the DNS string. The SGSN includes the profile index value portion of the CC as binary/decimal/hexadecimal digits (type based on the configuration) after the APN network identification. The charging characteristic value is taken from the subscription record selected for the subscriber during APN selection. This enables the SGSN to select a GGSN based on the charging characteristics information.
After appending the charging characteristic the DNS string will take the following form: <apn_network_id>.<profile_index>.<apn_operator_id >. The profile index in the following example has a value 10: quicknet.com.uk.1010.mnc234.mcc027.gprs.
If the RNC_ID information is configured to be a part of the APN name, and if inclusion of the profile index of the charging characteristics information is enabled (per this enhancement) before the DNS query is sent, then the profile index is included after the included RNC_ID and the DNS APN name will appear in the following form: <apn_network_id>.<rnc_id>.<profile_index>.<apn_op erator_id>. In the following example, the DNS query for a subscriber using RNC 0321 with the profile index of value 8 would appear as: quicknet.com.uk.0321.1000.mnc234.mcc027.gprs.
With this feature the operator can include the RNC_ID information with the name of the APN before the query is sent to the DNS. This feature makes it possible to select a GGSN based on the RNC_ID. Name format example: <apn_name>.<rnc_id>.<mncxxx>.<mccyyy>.gprs
With the RNC_ID inclusion enabled, the operator can also include the SCHAR (charging characteristic information) so that both the SCHAR and the RNC_ID information would be added to the name of the APN before the query is sent to the DNS. Name format example: <apn_name>.<rnc_id>.<schar>.<mncxxx>.<mccyyy>.gprs.
Default behavior has been changed to avoid PDP context deactivations resulting from GTP-C path failure detection due to messages containing erroneous restart counter change values.
Previous Behavior: The old default behavior was to have the SGSN detect GTP-C path failure based upon receiving restart counter changes in messages (Create PDP Context Response or Update PDP Context Response or Update PDP Context Request) from the GGSN and immediately begin PDP deactivation with a reactivation message. If the values in the messages are spurious, then this behavior could result in undesirable increases in network traffic due to bursts of deactivations/activations.
New Behavior: The new default behavior has the SGSN receive a restart counter change value and then the SGSN has the responsibility to verify a possible GTP-C path failure by issuing an Echo Request/Echo Response to the GGSN. Path failure will only be confirmed if the Echo Response contains a new restart counter value. Only after this confirmation of the path failure does the SGSN begin deactivation of PDP contexts.
Ciphering Algorithm Negotiation Failure - Actions Configurable - Behavioral Change
Previously, if there was no match between the ciphering algorithm from the MS and the ciphering algorithm configured in either the call control profile or the GPRS service configuration, then the SGSN performed Attach or RAU without ciphering.
|
l
|
Reject an incoming Attach / RAU when there is not a match between the MS and SGSN configured ciphering algorithms. The call Attach/RAU Rejection message can include a configurable GMM failure code.
|
The SGSN’s local QoS THP and ARP configurations can now override the QoS traffic handling priority (THP) value and allocation/retention priority (ARP) from an HLR subscription. This QoS capping can be done on a per-APN basis and is configurable in the APN profile for use through the operator policy function.
This functionality can differentiate home vs. roaming subscribers, and prevent visiting subscribers from receiving a high-tiered service. For example, a service provider could offer service differentiation using Ultra/Super/Standard service levels based upon QoS; this could justify charging a corporate customer more to use the Internet APN than would be charged to a consumer. This could be accomplished by controlling the traffic handling priority (THP) over the air interface, i.e. THP 1 = Ultra, THP 2 = Super and THP 3 = Standard. But this must be configured at the operator policy level to prevent a “roamed-in” customer from getting Ultra service if the foreign subscriber’s network provisions all of their customers with THP 1 on their HLRs.
A new custom33 dictionary is available. It is compliant with 3GPP TS 32.298 v.6.4.1 (custom6) with the following exceptions:
Checking access restriction data (ARD) in incoming insert subscriber data (ISD) messages is particularly useful in selectively restricting a subscriber in either 3G (UTRAN) or 2G (GERAN). In a previous release, the SGSN default behavior for an attach procedure was changed to check the ARD in the ISD and then accept or reject the subscriber with a configurable cause code included in the reject message.
The SGSN now supports diffserv code point (DSCP) marking of the GTP control plane messages on the Gn/Gp interface. This allows QoS to be set on GTP-C messages, and is useful if Gn/Gp is on a less than ideal link. DSCP marking is configurable via the CLI, with default = Best Effort Forwarding.
New configuration commands were added to create or remove a DSCP template which provides configuration of DSCP values for both control packets and data packets of different classes for traffic on Gb over IP.
The CLI commands which create or remove the DSCP templates are done at an SGSN-global level under the SGSN Global configuration mode; which also provides access to the new DSCP Template configuration mode.
These templates are associated with any of the configured GPRS services which allows that service to apply the configured DSCP values for all downlink packets sent out from the SGSN. If there is no profile associated with the GPRS service, the SGSN uses the default “Best Effort” DSCP values for both control and data packets.
The grouping configuration ranges for T1 and E1 channels has been enhanced. The SGSN now supports the full 0-31 timeslots for Frame Relay (channelized) port configuration, 32 for E1 and 24 for T1.
Previously, the SGSN allowed Gb/Iu Flex subscriber offloading only as per the specification-defined NULL NRI in P-TMSI and Non-Broadcast LAC/RAC mechanism. However, not all RNCs and BSSs support NULL-NRI.
The SGSN now supports Gb/Iu Flex subscriber offloading from one SGSN to another specific SGSN in a 2G/3G pool. In addition, the operator can configure the offloading Target NRI in P-TMSI, and the quantity to off load to the Target. This can be used to provide load balancing, or to off load a single node in pool, take it out of service for whatever reason (e.g., maintenance).
The SGSN can now measure the control plane packet delay for GTP-C signaling messages on the SGSN’s Gn/Gp interface towards the GGSN. If the delay crosses a configurable threshold, an alarm will be generated to prompt the operator.
A delay trap is generated when the GGSN response to an ECHO message request is delayed more than a configured amount of time and for a configured number of consecutive responses. When this occurs, the GGSN will be flagged as experiencing delay.
A clear delay trap is generated when successive ECHO Response (number of successive responses to detect a delay clearance is configurable), are received from a GGSN previously flagged as experiencing delay.
The SGSN now supports enhanced link aggregation (LAG) within ports on different side-by-side XGLCs. Ports can be from multiple XGLCs with some cards in L2 (side-by-side) redundancy.
LAG works by exchanging control packets (Link Aggregation Control Marker Protocol) over configured physical ports with peers to reach agreement on an aggregation of links. LAG sends and receives the control packets directly on physical ports attached to different XGLCs.
The link aggregation feature provides higher aggregated bandwidth, auto-negotiation, and recovery when a member port link goes down. With side-by-side redundancy on the XGLC, link aggregation supports horizontal ports from both XGLC cards.
For a PDP context request, an invalid APN occurs when none of the APNs in the HLR subscriber profile match the APN sent by the subscriber. The SGSN can now be provisioned to override an invalid APN even when a user has a wildcard APN in the HLR profile. The SGSN’s existing default APN functionality has been enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a Webpage informing the user of the error and prompting to subscribe for services.
Previously, if the required subscription APN was not present in subscriber profile, activation would be rejected.
The Lawful Intercept buffering feature has been enhanced to increase the number of call content records that can be buffered (or held in the buffer). For details, refer to the ASR 5000 Series Lawful Intercept Configuration Guide.
Previously, the SGSN supported GGSN selection for an APN only through operator policy, and supported a single pool of up to 16 GGSN addresses which were selected in round robin fashion.
The SGSN now supports configuration of multiple pools of GGSNs. As part of DNS resolution, the operator can use operator policies to prioritize local GGSNs versus remote ones. This function is built upon existing load balancing algorithms in which weight and priority are configured per GGSN. With the multiple GGSN pools feature, at this time, only the weight algorithm is used for selection. So with the primary GGSN pool used first and the secondary pool used when no primary GGSNs are available.
The SGSN first selects a primary pool and then GGSNs within that primary pool; employing a round robin mechanism for selection. If none of the GGSNs in a pool are available for activation, then the SGSN proceeds with activation selecting a GGSN from a secondary pool on the basis of assigned weight. A GGSN is considered unavailable when it does not respond to GTP Requests after a configurable number of retries over a configurable time period. Path failure is detected via GTP-echo.
The SGSN now provides the ability to map a maximum bit rate (MBR) value (provided by the HLR) to an HSPA MBR value. The mapped value is selected based on the matching MBR value obtained from the HLR subscription. QoS negotiation then occurs based on the converted value.
This feature is available within the operator policy framework. MBR mapping is configured via new keywords added to the qos class command in the APN Profile configuration mode. A maximum of four values can be mapped per QoS per APN. For details, refer to CSCzn32233 in the CLI Syntax section of the Interface Changes section of this release note.
NOTE: To enable this feature the qos prefer-as-cap, also a command in the APN Profile configuration mode, must be set to either both-hlr-and-local or to hlr subscription.
Refer to SGSN Modified Commands in the Configuration chapter of this document and to the Cisco ASR 5000 Series Command Line Interface Reference for details of the changes to the CLI.
Managing Path Failure Detection due to Restart Counter Change - Behavioral Change
The SGSN now provides the ability to manage GTP-C path failures detected as a result of spurious restart counter change messages received from the GGSN.
When the SGSN detects GTP-C path failure between the SGSN and the GGSN, the SGSN now assumes PDP sessions at the GGSN are lost and the SGSN deactivates those PDP sessions towards the UE with an indication that the UE should activate the PDP session again. Detection is based on receipt of restart counter change values in messages (Create PDP Context Response or Update PDP Context Response or Update PDP Context Request) which can be spurious. Potentially, this scenario can increase traffic within the operator’s network.
Various enhancements have been made to manage the resulting service deactivations and activations which would cause needlessly large bursts of network traffic if the restart counter change messages from the GGSN are erroneous:
|
l
|
New default behavior defined for handling GTP-C path failures detected as a result of erroneous restart counter changes received from the GGSN. See details in the Operator Notes.
|
Previously, the following parameters were available for configuration and for statistics display when the SS7 link was configured for lowspeed:
Previously, the following parameters were available for configuration and for statistics display when the SS7 link was configured for highspeed:
In accordance with specification Q.703, now EIM parameters are only available when SS7 link is configured for highspeed and AERM/SUERM parameters are only available when SS7 link is configured for lowspeed.
The SGSN is performing trials for support of S3/S4 interfaces to enable simultaneous access between 2G and 3G networks and LTE networks with MME and S-GW.
It is now possible to configure the SGSN to append LAC and RAC info to an APN DNS query for GGSN selection. It is expected that the DNS will use this information to determine the GGSN to route the APN.
For example, roaming subscribers using a specific APN may want to be directed to the closest GGSN. This can be achieved by having an operator policy for roaming subscribers associated with an APN profile that includes a configuration specifying that geographical information from the LAC/RAC be appended to the APN. This is then used as the DNS query string but does not modify the APN string being sent to the GGSN.
The SGSN now supports the PSC3 with PSC2-level capacity. This means the PSC3 in an SGSN currently supports the same number of subscribers as the SGSN with PSC2 cards. No special configuration is required.
The Cisco SGSN now supports Packet Temporary Mobile Subscriber Identity (P-TMSI) signature reallocation for all types of routing area update (RAU) events.
The P-TMSI is a temporary identity issued to a GPRS enabled mobile, unique within a given RA (routing area), and is used by the GPRS network to page the specified mobile. When enabled, the SGSN sends a P-TMSI signature to the MS in an RAU Accept message, and the MS must include the P-TMSI Signature in the next RAU request for the SGSN to compare with the original signature.
You can now configure the frequency and interval of P-TMSI signature reallocation for Periodic RAU and Normal RAU events. In this way, the SGSN can change the P-TMSI assigned to the MS as often as needed to maintain confidentiality of an MS when roaming.
The “default” and “no” keywords in the qos class command (APN Profile configuration mode) have been replaced resulting in the following behavioral changes:
Prior to release 12, using the “default” keyword in the qos class command resulted in only a few QoS class parameters being set to predefined values and “default” was not applicable to an entire QoS class. As well, using the “no” keyword invalidated the local configuration for the entire class identified in the command.
New behavior in release 12: The new “all-values” keyword configures predefined values for all the QoS parameters within a QoS class when the keyword is invoked. Until then, there are no values configured for QoS parameters, primarily to ensure that when the QoS preference is set to “both-hlr-and-local” (since the least of the HLR and local values is considered), the SGSN does not always select the locally predefined values as they often are the lowest possible values for these parameters. This change provides a simple method to specify that all the parameters of a given QoS class, or simply to an individual, specified QoS parameter, be assigned some predefined values. The new “remove” keyword deletes the configured value(s) for an individual QoS parameter or for all parameters for a specified QoS class.
RAI is no longer included automatically. Inclusion is operator configurable and for the following list of message types:
|
l
|
|
l
|
In previous releases, the SGSN partially supported reordering out-of-order segments coming from the same SNDCP N-PDU. If the first N-PDU segment came after subsequent segments, then the entire N-PDU was dropped.
Now, the SGSN fully supports reordering out-of-order segments coming from the same SNDCP N-PDU. The SGSN waits the configured amount of time for all segments of the N-PDU to arrive. If all the segments are not received before the timer expiries, then all queued segments are dropped.
The SGSN is trailing support for the S6d interface between the SGSN and the HSS. This will enable the SGSN to get subscription details of a 4G user from the HSS when user tries to register with the SGSN, either as part of an Inter-RAT handoff from 4G, or while attaching into 3G or 2G access.
The SGSN now allows settings to be configured with finer granularity for several of the SCTP timers:
For syntax details, refer to CSCzn15895 (130556) / CSCzn16886 (131704) in the Interface Changes section.
Previously, the SGSN provides an authentication procedures for standard GMM events like Attach, Detach, RAU, and Service-Request, and SMS events such as Activate, all with support for 1-in-N Authenticate functionality. The SGSN did not provide the capability to authenticate MO/MT SMS events.
Now, the authentication functionality has been expanded to the Gs interface where the SGSN now supports configuration of the authentication repetition rate for SMS-MO and SMS-MT, for every nth event. This functionality is built on existing SMS CLI, with configurable MO and/or MT. The default is not to authenticate.
Previously, the SGSN supported restricting MO-SMS and MT-SMS only through SGSN operator policy configuration.
Now, the SGSN can restrict forwarding of SMS messages to specific SMSC addresses, in order to allow operators to block SMS traffic that cannot be charged for. This functionality supports multiple SMSCs and is configurable per SMSC address with a maximum of 10 addresses. It is also configurable for MO-SMS and/or MT-SMS messages.
Automatic Protection Switching (APS) is the ability of the system to detect failures on a working facility and switch to a designated backup facility. The failures are detected in the Multiplex Section of the SDH Overhead (MSOH) or Section Overhead (SOH) of SONET.
The SGSN now provides inter-card support of SONET APS and MSP (Multiplexed Switching Protection) functionality on the Optical Line Card 2 (OLC2) as specified in G.783 Annex A.
This section provides information on new Serving GPRS Support Node (SGSN) features in Release 12.1. Additional information on these features can be found in the SGSN Administration Guide, and in the CLI Reference Guide.
The configuration limits have increased from 32 to 128 for the maximum number of LACs, as a combined total for LACs configured, for pool-areas and non-pool-areas for a Gs Service.
The SGSN now fully supports regional subscription zone identities (RSZIs) in accordance with TS 23.008. The HLR stores a list of RSZIs; 10 per network destination code (NDC). The RSZI are comprised of the PLMN id and the zone code lists. The SGSN now enables the operator to define the zone code lists, to enable zone code checking, and to define the cause code for subscription rejection when it is due to regional subscription information failure.
The SGSN now supports the Network Requested PDP Context Activation (NRPCA) procedure for 3G attachments. Whenever there is downlink data at the GGSN for a subscriber, but there is no valid context for the already-established PDP address, the GGSN initiates an NRPCA procedure towards the SGSN. Prior to starting the NRPCA procedure, the GGSN either obtains the SGSN address from the HLR or uses the last SGSN address of the subscriber available at the GGSN. There are no interface changes to support this feature. Support is configured with existing CLI commands (network-initiated-pdp-activation, location-area-list) in the call-control-profile configuration mode and timers (T3385-timeout and max-actv-retransmission) are set in the SGSN service configuration mode.
For a PDP context request, an invalid APN occurs when none of the APNs in the HLR subscriber profile match the APN sent by the subscriber. The SGSN can now be provisioned to override an invalid APN even when a user has a wildcard APN in the HLR profile. The SGSN’s existing default APN functionality has been enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a Webpage informing the user of the error and prompting to subscribe for services.
Previously, if the required subscription APN was not present in subscriber profile, activation would be rejected.
The SGSN now provides the ability to configure default APN to be used in several different scenarios:
• Use the APN in the first subscription record as a default APN. With this option the first subscription record with matching PDP type and PDP address will be used as the default APN. Here, first record means the first among the records received from HLR in that order. The default APN will be used if normal APN selection fails. This function is enabled via the new key-word ‘first-in-subscription’.
• Fallback to the APN in the first subscription record when configured default APN is not available. It is possible to configure a default APN to be used. However, if the configured default APN is not present in subscription then the SGSN will use the APN in the first subscription record with matching PDP type and PDP address. This function is enabled via the new keyword ‘fallback-to-first-in-subscription’.
• Prefer to use a single subscription record option, which specifies that if normal APN selection fails and if there is only one subscription record, then use the APN in that subscription record as the default APN. This is an optional configuration and is specified along with a default APN to be used. The configured default APN will be used when there are more than one subscription records. This feature is enabled via the new keyword ‘prefer-single-subscription’.
The SGSN’s local QoS THP and ARP configurations can now override the QoS traffic handling priority (THP) value and allocation/retention priority (ARP) from an HLR subscription. This QoS capping can be done on a per-APN basis and is configurable in the APN profile for use through the operator policy function.
This functionality can differentiate home vs. roaming subscribers, and prevent visiting subscribers from receiving a high-tiered service. For example, a service provider could offer service differentiation using Ultra/Super/Standard service levels based upon QoS; this could justify charging a corporate customer more to use the Internet APN than would be charged to a consumer. This could be accomplished by controlling the traffic handling priority (THP) over the air interface, i.e. THP 1 = Ultra, THP 2 = Super and THP 3 = Standard. But this must be configured at the operator policy level to prevent a “roamed-in” customer from getting Ultra service if the foreign subscriber’s network provisions all of their customers with THP 1 on their HLRs.
A new custom33 dictionary is available. It is compliant with 3GPP TS 32.298 v.6.4.1 (custom6) with the following exceptions:
Checking access restriction data (ARD) in incoming insert subscriber data (ISD) messages is particularly useful in selectively restricting a subscriber in either 3G (UTRAN) or 2G (GERAN). In a previous release, the SGSN default behavior for an attach procedure was changed to check the ARD in the ISD and then accept or reject the subscriber with a configurable cause code included in the reject message.
The SGSN now supports diffserv code point (DSCP) marking of the GTP control plane messages on the Gn/Gp interface. This allows QoS to be set on GTP-C messages, and is useful if Gn/Gp is on a less than ideal link. DSCP marking is configurable via the CLI, with default = Best Effort Forwarding.
The grouping configuration ranges for T1 and E1 channels has been enhanced. The SGSN now supports the full 0-31 timeslots for Frame Relay (channelized) port configuration, 32 for E1 and 24 for T1.
Previously, the SGSN allowed Gb/Iu Flex subscriber offloading only as per the specification-defined NULL NRI in P-TMSI and Non-Broadcast LAC/RAC mechanism. However, not all RNCs and BSSs support NULL-NRI.
The SGSN now supports Gb/Iu Flex subscriber offloading from one SGSN to another specific SGSN in a 2G/3G pool. In addition, the operator can configure the offloading Target NRI in P-TMSI, and the quantity to off load to the Target. This can be used to provide load balancing, or to off load a single node in pool, take it out of service for whatever reason (e.g., maintenance).
The SGSN can now measure the control plane packet delay for GTP-C signaling messages on the SGSN’s Gn/Gp interface towards the GGSN. If the delay crosses a configurable threshold, an alarm will be generated to prompt the operator.
A delay trap is generated when the GGSN response to an ECHO message request is delayed more than a configured amount of time and for a configured number of consecutive responses. When this occurs, the GGSN will be flagged as experiencing delay.
A clear delay trap is generated when successive ECHO Response (number of successive responses to detect a delay clearance is configurable), are received from a GGSN previously flagged as experiencing delay.
The SGSN now supports enhanced link aggregation (LAG) within ports on different side-by-side XGLCs. Ports can be from multiple XGLCs with some cards in L2 (side-by-side) redundancy.
LAG works by exchanging control packets (Link Aggregation Control Marker Protocol) over configured physical ports with peers to reach agreement on an aggregation of links. LAG sends and receives the control packets directly on physical ports attached to different XGLCs.
The link aggregation feature provides higher aggregated bandwidth, auto-negotiation, and recovery when a member port link goes down. With side-by-side redundancy on the XGLC, link aggregation supports horizontal ports from both XGLC cards.
For a PDP context request, an invalid APN occurs when none of the APNs in the HLR subscriber profile match the APN sent by the subscriber. The SGSN can now be provisioned to override an invalid APN even when a user has a wildcard APN in the HLR profile. The SGSN’s existing default APN functionality has been enhanced so that if a required subscription APN is not present in the subscriber profile, then the SGSN will now continue the activation with another configured 'dummy' APN. The call will be redirected, via the GGSN, to a Webpage informing the user of the error and prompting to subscribe for services.
Previously, if the required subscription APN was not present in subscriber profile, activation would be rejected.
The Lawful Intercept buffering feature has been enhanced to increase the number of call content records that can be buffered (or held in the buffer). For details, refer to the ASR 5000 Series Lawful Intercept Configuration Guide.
Previously, the SGSN supported GGSN selection for an APN only through operator policy, and supported a single pool of up to 16 GGSN addresses which were selected in round robin fashion.
The SGSN now supports configuration of multiple pools of GGSNs. As part of DNS resolution, the operator can use operator policies to prioritize local GGSNs versus remote ones. This function is built upon existing load balancing algorithms in which weight and priority are configured per GGSN. With the multiple GGSN pools feature, at this time, only the weight algorithm is used for selection. So with the primary GGSN pool used first and the secondary pool used when no primary GGSNs are available.
The SGSN first selects a primary pool and then GGSNs within that primary pool; employing a round robin mechanism for selection. If none of the GGSNs in a pool are available for activation, then the SGSN proceeds with activation selecting a GGSN from a secondary pool on the basis of assigned weight. A GGSN is considered unavailable when it does not respond to GTP Requests after a configurable number of retries over a configurable time period. Path failure is detected via GTP-echo.
The SGSN now provides the ability to map a maximum bit rate (MBR) value (provided by the HLR) to an HSPA MBR value. The mapped value is selected based on the matching MBR value obtained from the HLR subscription. QoS negotiation then occurs based on the converted value.
This feature is available within the operator policy framework. MBR mapping is configured via new keywords added to the qos class command in the APN Profile configuration mode. A maximum of four values can be mapped per QoS per APN. For details, refer to CSCzn32233 in the CLI Syntax section of the Interface Changes section of this release note.
NOTE: To enable this feature the qos prefer-as-cap, also a command in the APN Profile configuration mode, must be set to either both-hlr-and-local or to hlr subscription.
Refer to SGSN Modified Commands in the Configuration chapter of this document and to the Cisco ASR 5000 Series Command Line Interface Reference for details of the changes to the CLI.
Previously, the following parameters were available for configuration and for statistics display when the SS7 link was configured for lowspeed:
Previously, the following parameters were available for configuration and for statistics display when the SS7 link was configured for highspeed:
In accordance with specification Q.703, now EIM parameters are only available when SS7 link is configured for highspeed and AERM/SUERM parameters are only available when SS7 link is configured for lowspeed.
The SGSN is performing trials for support of S3/S4 interfaces to enable simultaneous access between 2G and 3G networks and LTE networks with MME and S-GW.
The SGSN now supports the PSC3 with PSC2-level capacity. This means the PSC3 in an SGSN currently supports the same number of subscribers as the SGSN with PSC2 cards. No special configuration is required.
The Cisco SGSN now supports Packet Temporary Mobile Subscriber Identity (P-TMSI) signature reallocation for all types of routing area update (RAU) events.
The P-TMSI is a temporary identity issued to a GPRS enabled mobile, unique within a given RA (routing area), and is used by the GPRS network to page the specified mobile. When enabled, the SGSN sends a P-TMSI signature to the MS in an RAU Accept message, and the MS must include the P-TMSI Signature in the next RAU request for the SGSN to compare with the original signature.
You can now configure the frequency and interval of P-TMSI signature reallocation for Periodic RAU and Normal RAU events. In this way, the SGSN can change the P-TMSI assigned to the MS as often as needed to maintain confidentiality of an MS when roaming.
The “default” and “no” keywords in the qos class command (APN Profile configuration mode) have been replaced resulting in the following behavioral changes:
Prior to release 12, using the “default” keyword in the qos class command resulted in only a few QoS class parameters being set to predefined values and “default” was not applicable to an entire QoS class. As well, using the “no” keyword invalidated the local configuration for the entire class identified in the command.
New behavior in release 12: The new “all-values” keyword configures predefined values for all the QoS parameters within a QoS class when the keyword is invoked. Until then, there are no values configured for QoS parameters, primarily to ensure that when the QoS preference is set to “both-hlr-and-local” (since the least of the HLR and local values is considered), the SGSN does not always select the locally predefined values as they often are the lowest possible values for these parameters. This change provides a simple method to specify that all the parameters of a given QoS class, or simply to an individual, specified QoS parameter, be assigned some predefined values. The new “remove” keyword deletes the configured value(s) for an individual QoS parameter or for all parameters for a specified QoS class.
RAI is no longer included automatically. Inclusion is operator configurable and for the following list of message types:
|
l
|
|
l
|
In previous releases, the SGSN partially supported reordering out-of-order segments coming from the same SNDCP N-PDU. If the first N-PDU segment came after subsequent segments, then the entire N-PDU was dropped.
Now, the SGSN fully supports reordering out-of-order segments coming from the same SNDCP N-PDU. The SGSN waits the configured amount of time for all segments of the N-PDU to arrive. If all the segments are not received before the timer expiries, then all queued segments are dropped.
The SGSN is trailing support for the S6d interface between the SGSN and the HSS. This will enable the SGSN to get subscription details of a 4G user from the HSS when user tries to register with the SGSN, either as part of an Inter-RAT handoff from 4G, or while attaching into 3G or 2G access.
The SGSN now allows settings to be configured with finer granularity for several of the SCTP timers:
For syntax details, refer to CSCzn15895 (130556) / CSCzn16886 (131704) in the Interface Changes section.
Previously, the SGSN provides an authentication procedures for standard GMM events like Attach, Detach, RAU, and Service-Request, and SMS events such as Activate, all with support for 1-in-N Authenticate functionality. The SGSN did not provide the capability to authenticate MO/MT SMS events.
Now, the authentication functionality has been expanded to the Gs interface where the SGSN now supports configuration of the authentication repetition rate for SMS-MO and SMS-MT, for every nth event. This functionality is built on existing SMS CLI, with configurable MO and/or MT. The default is not to authenticate.
Previously, the SGSN supported restricting MO-SMS and MT-SMS only through SGSN operator policy configuration.
Now, the SGSN can restrict forwarding of SMS messages to specific SMSC addresses, in order to allow operators to block SMS traffic that cannot be charged for. This functionality supports multiple SMSCs and is configurable per SMSC address with a maximum of 10 addresses. It is also configurable for MO-SMS and/or MT-SMS messages.
Automatic Protection Switching (APS) is the ability of the system to detect failures on a working facility and switch to a designated backup facility. The failures are detected in the Multiplex Section of the SDH Overhead (MSOH) or Section Overhead (SOH) of SONET.
The SGSN now provides inter-card support of SONET APS and MSP (Multiplexed Switching Protection) functionality on the Optical Line Card 2 (OLC2) as specified in G.783 Annex A.
This section provides information for new features for the Web Element Manager (WEM) application in Release 12.0.
The Web Element Manager is now supported on selected Cisco UCS servers running the custom Cisco MITG Red Hat Enterprise Linux (RHEL) v5.5 operating system (OS).
For detailed hardware platform and hard disk drive partition requirements, refer to the Web Element Manager Overview chapter of the Cisco Web Element Manager Installation and Configuration Guide. For installation information, refer to the Cisco MITG RHEL v5.5 OS Application Note.
IMPORTANT: The Cisco MITG RHEL v5.5 OS is a custom image that contains only those software packages required to support compatible Cisco MITG external software applications. Users must not install any other applications on servers running the Cisco MITG v5.5 OS. For detailed software compatibility information, refer to the Cisco MITG RHEL v5.5 OS Application Note. Multiple WEM servers can now be configured as part of a High Availability failover cluster via the use of Oracle Cluster software. Refer to Appendix A in the Cisco Web Element Manager Installation and Administration Guide for detailed information.
